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(54) Verfahren zur Verifikation eines Programms, welches in einer Sprache fur speicher- 
programmierbare Steuerungen vorliegt, durch einen Rechner 



(57) Zur Verifikation eines SPS-Programms wird 
das SPS-Programm auf einen endlichen Automaten 
abgebildet (701). Der endliche Automat wird unter Ver- 
wendung eines Binary-Decision Diagrams beschrieben 
(702). Eine zu verifizierende Eigenschaft des SPS-Pro- 



gramms, welches in einer formalen Spezrfikationsspra- 
che vorliegt, wird unter Verwendung einer symbol rschen 
Modelluberprufung uberpruft (703). 
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Abbildung eines SPS-Programms 
auf einen endlichen Automaten 






Beschreibung des endlichen Automaten 
mit Binary Decision Diagrams 
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Verifikation einer zu verifizierenden 
Eigenschaft des als Binary Decision 
Diagram beschriebenen SPS-Programms 
mit Symbolic Model-Checking 
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Beschreibung 

Die Notwendigkert der formalen Verif ikation von Programmer) wdchst mit der zunehmenden Verbreitung von Soft- 
ware und sorrrrt der Mdchtigkeit und der Komplexrtdt entwickefter Programme. 

Unter einer formalen Verrfikation ist im Rahmen dieses Dokumentes der Nachweis der Kbrrektheit eines Pro- 
gramms bezuglich einer formalen Spezifikation zu verstehen. Korrekt bedeutet in diesem Zusammenhang, daB alle 
mOglichen zeitlichen Verhaltensabtdufe des zu verifizierenden Programms mindestens eine vorgebbare spezifizierte 
Eigenschaft erfullen. 

Beispielsweise aus dem Dokumerrt [1] ist ein mathematisches KalkOI zur Verrfikation eines PASCAL-Programms 
bekannt. Dieses Verfahren ist jedoch in der Nachweisfuhrung sehr aufwendig und langwierig, an den wesentiichen 
Stellen ohne wirkungsvolle Werkzeugunterstutzung unter Verwendung eines Rechners und stellt hohe Anforderungen 
an die mathematische Qualif ikation eines Benutzer des Verfahrens, insbesondere in dem mathematischen Gebiet der 
Logik. 

Aus dem Dokumerrt [2] ist die Umsetzung von logischen Formeln zur Beschreibung eines endlichen Automaten in 
eine sog. Binaiy-Decision-Diagram-Darstellung (BDD-Darstellung) bekannt. 

Femer ist aus dem Dokument[3] ein Verfahren zur sog. Modelluberprufung (Model-Checking) auf einen endlichen 
Automaten, der mit Hitfe von BDDs reprdsentiert wird, bekannt 

Beispielsweise aus den Dokumenten [4]. [5] und [6] sind Verfahren zur formalen Verrfikation eines VHDL-Pro- 
gramms bezuglich vorgebbarer zu verif izierender Eigenschaften des Programms bekannt. 

Die Hardwarebeschreibungssprache VHDL dient zur Simulation von elektronischer Hardware. Neben der Syntax 
ist auch die Semantik von VHDL eindeutig festgelegt. 

Ein Programm zur speicherprogrammierbaren Steuerung (SPS-Programm) kann dagegen in ein auf einem Rech- 
ner ablauffdhiges Maschinenprogramm Qbersetzt werden. 

Ferner enthaften SPS-Programme ZeHbefehle, beispielsweise sog. Timer und unterschiedliche Korrelationen zwi- 
schen Timern, beispielsweise der Ablauf von verschiedenen Timern zu urrterschiedlichen Zerten. 

Mit den bisher bekarmten Verfahren ist es nicht mdglich, eine formale Verif ikation fur SPS-Programme durchzufuh- 

ren. 

Somit liegt der Erfindung das Problem zugrunde, ein Verfahren zur formalen Verif ikation von SPS-Programmen 
anzugeben. 

Das Problem wind durch das Verfahren gem. Patentanspruch 1 gel&st. 

Das Programm liegt in einer Sprache fur speicherprogrammierbare Steuerungen, die im weiteren als SPS-Pro- 
gramme bezeichnet werden, vor. Fur das SPS-Programm wird mindestens eine vorgebbare Eigenschaft des Pro- 
gramms in einer formalen Spezifikationssprache beschrieben, die mit dem Verfahren verif iziert wird. Das SPS- 
Programm wird auf einen endlichen Automaten abgebikJet und der endliche Automat wind unter Verwendung von BDDs 
beschrieben. Die zu verrf izierende Eigenschaft wird anhand des als BDD beschrieben en endlichen Automaten unter 
Verwendung der sog. symbolischen Modelluberprufung (Symbolic Modell Checking) uberpruft 

Das Verfahren weist einige erhebliche Vorteile auf. Durch das Verfahren wird es erstmals mOglich, auch SPS-Pro- 
gramme mit den spezifischen Eigenschaften von SPS-Programmen, der erhOhten Komplexitat sowie den in den SPS- 
Programm enthattenen Zertbefehlen und Timern und der Struktur von unendtichen Befehlsschleifen, zu verif izieren. 

Ein weiterer Vorteil des Verfahrens ist in der Berucksichtigung von exakten Spezrf ikationen der Eigenschaften einer 
Steuerung in der formalen Spezifikationssprache zu sehen. Mit diesem Verfahren wird es sehr einfach und mit absol li- 
ter VeriaBlichkert mOglich, die Abnahme der Steuerung, die mit dem SPS-Programm beschrieben wird, mrt einer voll- 
automatischen und vollstandigen Programmuberprufung durch den Auftraggeber zu realisieren. 

Ein weiterer Vorteil des Verfahrens ist in der Berucksichtigung des Umgebungsverhaltens zu sehen. Das gesteu- 
erte System meldet in der Regel nicht alle mOglichen durch die verwendeten Datentypen erlaubten Datensequenzen 
an die Steuerung zuruck, sondem nur eine Auswahl. So kann z.B. ein Temperaturfuhler fur absolute Temperaturen 
keine negativen Werte melden. Ein Winkelmesser, der Winkelgrade meldet. wird nur Werte zwi sehen 0 und 360 liefern. 
Die Ruckmeldungen des gesteuerten Systems kOnnen aber auch temporal eingeschrdnkt sein. So mag die physikali- 
sche Realisierung der gesteuerten Anlage z.B. garantieren, daB vor einem bestimmten Ereignis B immer ein Ereignis 
A aufgetreten sein muss. Ein SPS-Programm berucksichtigt i.d.R. derartiges (Umgebungs-)Verhalten. 

Ein Vorteil des hier beschriebenen Verfahrens ist u. a. darin zu sehen, daB die formale Spezifikationssprache die 
Formulierung dieser Umgebungseigenschaften und damit deren Berucksichtigung ermOglicht Weiterhin kOnnen derar- 
tige Annahmen dazu dienen, das Verhatten von nicht modellierten Steuerungskomponenten wie z.B. komplexen Funk- 
tionsbausteinen, Timern, Zdhlern, in einer der Verifikati nsaufgabe angemessenen Detaillierung abstrahiert zu 
beschreiben, was im weiteren r&her erlautert wird. 

Ferner wird durch dieses Verfahren eine Fehlererkennung in fruhen Entwurfsphasen bei komplexen SPS-Program- 
men mGglich, was zu einer erheblichen Produktivrtatssteigerung und Kostensenkung fuhrt. 

Auch ist ein erheblicher Vorteil des Verfahrens in der Sichertiert zu sehen, daB im Falle der Korr kthert des SPS- 
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Programms bzgl. einer vorgegebenen Eigenschaft ein mathematisch exakter Nachweis dafur gefunden wind. Dies fuhrt 
zu iner sehr vorteilhaften Einsatzmdglichkeit des Verfahrens bei der Zertifizierung von Steuerungssoftware, also bei 
SPS-Programmen. 

Auch wird durch das Verfahren eine regressive Uberprufung nach Anderungen des Programms leicht mOglich. 
Dies fuhrt zu einer sehr vorteilhaften EinsatzmOglichkeit des Verfahrens im Software-LebenszyMus von der Projektier- 
phase bis zur Wartungsphase der Sofware im Feldeinsatz. 

Vorteilhafte WeiterbikJungen der Erf indung ergeben sich aus den abhangigen Anspruchen. 

Es ist vorteilhaft, daB fur den Fall, daB das Programm die zu verifizierende Eigenschaft nicht aufweist, eine Wider- 
legungssequenz ermrttett wird und einem Benutzer bei Bedarf angezeigt wird. Dadurch wird es fur den Benutzer leicht 
erkennbar, was die Ursache fur die fehlende Eigenschaft des SPS-Programmes ist 

In den Rguren sind AusfGhrungsbeispiele der Erfindung dargesteltt die im weiteren naher eriautert werden. 

Es zeigen 

Rg. 1 eine Skizze, in der in Form ernes Blockdiagramms das Prinzip der formalen Verrf ikation dargesteltt ist; 
Rg. 2 eine Skizze, in der eine logische Darstellung eines SPS-Programm zur Steuerung der Bearbeitung eines 
WerkstOckes dargesteltt ist; 

Rg. 3 eine Zustandsgraphenbeschreibung, eines Teils des SPS-Programms zur Bearbeitung des Werkstucks aus 

Rg. 2; 

Rg. 4 eine Widerlegungssequenz, in der eine MOglichkeit der Ausgabe dargestellt ist. wenn das SPS-Programm 

die zu uberprufende Eigenschaft nicht aufweist; 
Rg. 5 die Widerlegungssequenz in Form einer Skizze fur das SPS-Programm zur Bearbeitung des Werkstucks 

aus Rg. 2; 

Rg. 6 ein Zustandsgraph eines eirtfachen zweiten Ausfuhrungsbeispiels eines SPS-Programms; 
Rg. 7 ein Ablaufcfiagramm, in dem die einzelnen Verfahrensschritte des Verfahrens dargesteltt sind. 

In Rg. 1 ist in Form eines Blockdiagramms eine skizzenhafte Strukturbeschreibung des Verfahrens zur Verif ikation 
eines SPS-Programms SProg dargesteltt. Das Verfahren wird mit Hitfe eines Rechners R durchgefuhrt 
In der Rgur 1 ist eine formale Verif ikation FV symbolisch als ein eigener Block dargesteltt 
Der formalen Verif ikation FV wird das SPS-Programm SProg als eine Form der Systembeschreibung zugefuhrt 
Femer wird der formalen Verif ikation FV mindestens eine zu verif izierende Eigenschaft VE zugefuhrt Die zu veri- 
f izierende Eigenschaft ist in einer formalen Spezifikationssprache beschrieben. 

Weitertiin kOnnen der formalen Verifikation FV eine Oder mehrere Annahmen A uber das Verhatten der Umgebung 
Oder der nicht modellierter Komponenten zugefuhrt werden. Diese Annahmen kCnnen ebenfalls in der formalen Spezi- 
f ikationssprache beschrieben werden. 

Ein SPS-Programm SProg kann in unterschiedlichster Art und Weise dargesteltt werden, wie im weiteren beschrie- 
ben wird, z. B. in Form eines Zustandsgraphenprogramms Oder auch in Form sog. Anweisungslisten AWL Auch die zu 
verifizierende Eigenschaft VE kann in unterschiedlicher Form beschrieben sein, beispielsweise in einer sog. temporal- 
logischen Beschreibungsform. Nachdem auf das SPS-Programm SProg die formale Verif ikation FV ausgefuhrt wird, 
ergibt sich entweder, daB die zu verifizierende Eigenschaft VE fur das SPS-Programm SProg gift oder auch nicht Es 
ist in diesem Verfahren ebenso vorgesehen, eine beliebige Anzahl von Eigenschaften VE in einem Verfahren zu Qber- 
prufen. 

Ist die mindestens eine zu verifizierende Eigenschaft VE gegeben, so wird durch cfie formale Verifikation FV ein 
Korrektheitsnachweis gefuhrt, der beispielsweise in einer Kbrrektheitsliste KL auf einem Bildschirm BS einem Benutzer 
des Verfahrens dargesteltt werden kann. Gilt jedoch die Eigenschaft nicht so kann eine Widerlegungssequenz WS in 
einer Weiterbildung des Verfahrens gebildet werden und beispielsweise ebenso dem Benutzer in Form in einer visuali- 
sierten Widerlegungssequenz WS dargesteltt werden. 

Bei dem Verfahren zur formalen Verifikation wird das SPS-Programm SProg auf mindestens einen endlichen Auto- 
maten abgebikfet mit dem das Systemverhalten modeltiert wird. Die Abbildung erfolgt, wie im weiteren beschrieben 
wird, automatisch durch den Rechner R. 

Aus Grunden der Vereirrfachung wird im folgenden nur die Konstellation beschrieben, daB sowohl das Verfahren 
zur formalen Verifikation des SPS-Programms SProg als auch die Programmausfuhrung des SPS-Programms SProg 
auf demselben Rechner R durchgefuhrt werden. Selbstverstandlich kfrinen Uberprufung und Ausfuhrung auch auf ver- 
schiedenen Rechnem durchgefuhrt werden. 

Erstes Ausfuhrungsbeispiel : 

In einem ersten Ausfuhrungsbeispiel wird das Prinzip des Verfahrens anhand der Verifikation eines SPS-Pro- 
gramms SProg, das in Form einer Zustandsgraphenbeschreibung vorfiegt, beschrieben. Urrter einer Zustandsgraphen- 



EP 0828 215 A1 



beschreibungssprache ist beispielsweise die sog. Zustarxfegraphenprogrammiersprache des Software-Werkzeugs 
HiGraph zu verstehen. 

In dem ersten Ausfuhrungsbeispiel wird eine Werkzeugmaschinensteuerung eriautert. Diese ist in Rg. 2 darge- 
stelft. Von dem Rechner R wird das SPS-Programm SProg ausgefuhrt Mit dem SPS-Programm SProg wird ein Schlrt- 
ten S, auf dem sich eine erste Spindel SP1 und eine zweite Spindel SP2 befinden, bewegt Der Schlrtten S wird 
zwischen einer Werkzeugwechselposition P1 und einer Bearbertungsposition P2 hin und her bewegt An der Bearbei- 
tungsposition P2 wird ein Werkstuck W beispielsweise unter Zugabe von Kuhlmrttel K mrt auf den Spindeln, SP1 , SP2 
aufgesetzten Werkzeugen bearbeitet 

So werden beispielsweise mit Bohrern, die auf den Spindeln SP1 , SP2 aufgebracht sind, LOcher in das Werkstuck 
W gebohrt. Das SPS-Programm SProg, welches in Form der Zustandsgraphenbeschreibungssprache vorliegt ist in 
diesem Beispielsfall in drei Ebenen aufgeteitt, in eine Errtscheidungsebene EE, in eine Kbordnierungsebene KE und in 
eine Antriebsebene AE. Die einzelnen Ebenen EE, KE, AE sind beispielsweise durch mehrere Komponenten realisiert, 
die jeweils durch einzelne Zustandsgraphen beschrieben sind. Die Zustandsgraphen kOnnen untereinander kommuni- 
zieren und mrt der Umgebung beispielsweise uber einen Nachrichtenaustausch Oder uber globale Variablen kommuni- 
zieren. 

In einem Zustandsgraphen Entscheidung ZE der Entscheidungsebene EE wird beispielsweise entschieden, einen 
RGckJauf des Schlittens S durch Abgabe einer Nachricht J=ireigabe_Rucklauf" FR einzuleiten. Die Nachricht 
f reigabe_RucWaur FR wird an einen Zustandsgraphen RucWauf ZR ubermrttett. Der Zustandsgraph RucWauf ZR 
reagiert auf die Nachricht J = reigabe_RucWairT FR beispielsweise mit einem Befehl J>ef_spindel_aus m SA an einen 
Zustandsgraphen Spindel 1 ZS1 der Antriebsebene AE. In dem Zustandsgraphen Spindel 1 ZS1 wird beispielsweise 
daraufhin die erste Spindel SP1 durch Rucksetzen eines Aktors mit einem Befehl £pindel_aus" auf einen Wert 0 aus- 
geschaftet 

Allgemein kann auf ein SPS-Programm SProg ublicherweise noch von einer ubergeordneten Lertsteuerung LS Ein- 
fluB ausgeubt werden. So ist es beispielsweise mdglich, daB den Einherten des SPS-Programms SProg ein Signal 
£lle_spindeln_aus m ASA zugefuhrt wird, auf die cfie Elemente mit dem Ausschatten der Spindeln SP1 , SP2 reagieren 
mOssen. In dem SPS-Programm SProg kOnnen eine beliebige Anzahl von Zustandsgraphen enthalten sein, beispiels- 
weise ein Zustandsgraph zur Steuerung des Schlittens ZS Oder auch ein Zustandsgraph ZS2 zur Steuerung der zwet- 
ten Spindel SP2. Auch ist es beispielsweise mOglich, daB ein Zustandsgraph ZK zur Steuerung der ZufOhrung des 
Kuhlmittels Kvorgesehen ist 

In Rg. 3 ist ein eirrfaches Beispiel des Zustandsgraphen Spindel 1 ZS1 dargesteltt Mrt dem Zustandsgraphen Spin- 
del 1 ZS1 wird eine Ansteuerung der ersten Spindel SP1 beschrieben. Der Zustandsgraph Spindel 1 ZS1 enthait einen 
Irrrtialzustand INIT. Ferner enthait er wertere Zustande 2, 4 und 6. Ein Zustandsubergang beispielsweise von Zustand 6 
nach Zustand 4 erfolgt genau dann, wenn die Transitionsbedingung 10 erfullt ist, in diesem Beispielsfall dann, wenn die 
Werte der Variablen Befehl ^pindel_ein = T oder £lle_spindein_ein = 1~ gift. 

In den Zustdnden 2, 4 und 6 werden Aktionen ausgefuhrt, solange sich das SPS-Programm in den jeweiligen 
Zustanden 2, 4, 6 befindet. 

In dem Zustand 4 wird beispielsweise der Wert einer Variable jSpindel_ein m auf den Wert 1 gesetzt, wodurch die 
erste Spindel SP1 aktiviert wird. 

In dem Zustand 6 wird beispielsweise der Wert der Variable Spindel_ein m auf den Wert 0 gesetzt, wodurch die 
erste Spindel SP1 deaktiviert wird. 

Fur die fbrmale Verrfikation FV wird von einem Benutzer mindestens eine Eiger^chaft VE vorgegeben, die bei der 
fbrmalen Verif ikation FV uberpruft wird. Unter der Eigenschaft VE ist eine Spezifikatton des SPS-Programms SProg zu 
verstehen, die eine exakt ddinierte Bedeutung aufweist. Die Eigenschaft VE liegt Qblicherwefse in einer formalen Spe- 
zrf ikationssprache vor. 

Mit einer Spezrf ikation wird ausgedruckt, was das SPS-Programm SProg tun dart bzw. nicht tun darf oder was 
unbecfingt durch das SPS-Programm SProg geschehen muB. 

Es ist in einer Weiterbildung des Verfahrens mGglich, zusfflzlich zu der Eigenschaft VE auch Annahmen vorzuge- 
ben, die ebenso bei der fbrmalen Verifikation FV berucksichtigt werden. Die Annahmen werden ebenfalls in einer fbr- 
malen Spezrf ikationssprache beschrieben. 

Allgemein kOnnen eine beliebige Anzahl von Eigenschaften VE und Annahmen in dem Verfahren beschrieben und 
bei der fbrmalen Verifikation FV berucksichtigt werden. Mit Annahmen werden Spezifikationen uber eine Umgebung 
des jeweils zu verif izierenden SPS-Programms SProg beschrieben, die beispielsweise der Benutzer des Verfahrens 
voraussetzt. 

Zur einfachen Beschreibung der Eigenschaften und Annahmen kOnnen beispielsweise naturiichsprachliche Scha- 
Wonen mit einer jeweils exakten Bedeutung verwendet werden, die zur einfacheren Darstellung ohne Einschrankung 
der Ailgemeingurtigkert im werteren verwendet wird. 

Im Rahmen dieses Dokumentes werden zur einfacheren Darstellung beispielsweise folgende typische syntakti- 
schen Schablonen verwendet: 



EP 0 828 215 A1 



- IMMER GILT... 

- NIE GILT ... 

- SOLANGE ... GILT... 

- SOBALD ... GILT... 

- SOBALD ... DANN SOLANGE ... BIS ... 

Eine denkbare zu verifizierende Eigenschaft VE fur das erste Ausfuhrungsbeispiel ist z. B., daB die Variable 
jSpindel_ein m errtweder sofort Oder spatestens nach einem SPS-Zyklus den Wert 0 aufweist, fur den Fall, daB die 
Variable (f bef_spindel_aus w Oder die Variable Alle_spindeln_aus~ den Wert 1 aufweist 

Dies kann zur einfacheren Darstellbarkeit beispielsweise in folgender fbrmalen Spezrf ikationssprache formuliert 
werden: 
SOLANGE 

bef_spindel_aus == 1 Oder alle_spindeln_aus ==1 
GILT spatestens nach einem ZyWus 
spindel_ein == 0. 

Durch die formale Verifikation FV wird uberpruft, ob die Eigenschaft VE for das SPS-Programm SProg, d. h. in 
jedem mOglichen Ablauf des SPS-Programms SProg, gilt 

Im Fehlerfall, d. h. fur den Fall, daB die Eigenschaft VE fur das SPS-Programm SProg nicht gilt, wird in einer Wei- 
terbildung des Verfahrens eine Widerlegungssequenz WS ermrttett. In der Widerlegungssequenz WS werden ausge- 
hend vom Initialstatusvektor INIT, in dem alle VariaWen ihren Initiafwert haben, die Werte der EingabevariaWen, 
AusgabevariaWen und Programmvariablen for jeden SPS-Zyklus angegeben, bis feststeht. daB die ermittelte Folge der 
SPS-ZyMen die zu verifizierende Eigenschaft nicht aufweist 

Es ist jedoch nicht unbedingt der Fall, daB die ermittette Widerlegungssequenz WS echte FehJer beschreibt Es 
kann auch vorkommen, daB mit der Widerlegungssequenz WS lediglich unrealistisches Verhalten des SPS-Pro- 
gramms SProg widergespiegeft wird. Die erkiart sich daraus, daB bei der fbrmalen Verifikation FV zunSchst jegliche 
Information uber die Umgebung, d. h. die Schnrttstellen des SPS-Programms SProg. beispielsweise Qber die Lertsteue- 
rung LS, nicht bekanrrt ist 

Allgemein sind all diejenigen Teile eines SPS-Programms SProg unbekannt die nicht Bestandteil des zu verif izie- 
renden SPS-Programms SProg sind, jedoch beispielsweise uber gemeinsame Speicherberetche in Verbindung zu dem 
zu verrfizierenden SPS-Programm SProg stehen. 

Bei dem Verfahren wird zunachst der Umgebung des zu verif izierenden SPS-Programms ein beliebiges Verhalten 
untersteltt. 

Mit HiHe von Annahmen, die einer Schnittstellenspezifikation entsprechen, hat der Benutzer <fie MOglichkeit, ein 
vorgebbares Umgebungsverhaften fur das zu verifizierende SPS-Programm SProg zu spezrf izieren. In diesem Fall 
bedeutet eine erfolgreiche Verifikation, daB das SPS-Programm die zu verifizierende Eigenschaft urrter den getrofffenen 
Annahmen erfultt 

Beispielsweise kann man in dem ersten Ausfuhrungsbeispiel die fehlende Information uber konsistentes Befehfe- 
verhatten der Lertsteuerung LS, die sich auBerhalb des beispielhaft zu verif izierenden Zustandsgraphen Spindel 1 ZS1 
befindet, in folgender Annahme formulieren: 
IMMER GILT 

a!le_spindeJn_ein == 0 

ODER 

alle_spindeln_aus == 0 

In diesem Fall wird die Annahme getroffen, daB von der Lertsteuerung LS niemals gleichzertig ein Befehl 
^lle_spindeln_ein" und ^Ile_spindeln_aus" an die Elemente des SPS-Programms SProg Obermitteit werden. Eine 
wertere MOglichkeit des Einsatzes einer Annahme ist beispielsweise dann vorteilhaft, wenn bestimmte Verhaftensab- 
ISufe bei der fbrmalen Verifikation FV nicht berucksichtigt werden sollen. MOchte man beispielsweise den Handbetrieb 
der Einheit bei der fbrmalen Verifikation FV ausschlieBen, kann beispielsweise folgende Annahme uber eine speziell 
fur den Handbetrieb vorgesehene Variable J>a_hand* getroffen werden: 
IMMER 

ba_hand == 0 

In Fig. 4 ist eine Widerlegungssequenz WS mit folgenden berucksichtigten Variablen dargestellt: 

[Spindel 1, alle__spindeln_ein], 

- [Spindel 1, alle_spindeln_aus], 

- [Spindel 1 , bef_spindel_ein], 

- [Spindel 1 , bef_spindel_aus], 
[Spindel 1, Spindel_ein]. 
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tn jeder Spatte der Widerlegungssequenz WS wird jeweils zu einem eindeutig bezeichneten SPS-ZyWus der Wert 
der jeweiligen Variable in der entsprechenden Zeile dargestellt 

Aus Fig. 4 ist beispielsweise ersichtlich, daB in dem SPS-Zyklus 5 die erste Spindel SP1 eingeschaltet ist, obwohl 
in dem SPS-ZyWus 4, d. h. einem SPS-Zyklus zuvor, der Befehl Spindel_aus SA in Form des Wertes 1 der Variable 
[Spindel 1, bef_Spindel_aus] in dem SPS-Programm SProg vorlag. 

Oiese Fehlersituation ist in der Fig. 5 dargestellt Wahrend der RucWaufphase wird in diesem Fall der Befehl 
Spindel_aus SA von dem Zustandsgraph RucWauf ZR gesendet. Gleichzertig wird jedoch von der Leitsteuerung LS der 
Befehl alle_spindeln_ein ASE gesendet. 

In dem SPS-Programm SProg wird jedoch der Befehl Spindel_aus SA von dem Zustandsgraphen RucWauf ZR 
ignoriert. Es ist fur den Benutzer nun leicht, den Fehler in dem SPS-Programm SProg zu erkertnen. 

In diesem Fall ist der Grund fur das Fehtverhalten, beispielsweise darin zu sehen, daB von dem Zustand 6 des 
Zustandsgraphen Spindel 1 ZS1 aufgrund des Befehls der Leitsteuerung LS alle_spindeln_ein ASE in den Zustand 4 
ubergegangen wird, urn die erste Spindel S1 zu aktivieren. Es werden jedoch in der Transitionsbedingung (vgl. Rg. 3) 
keine Ausschaltbefehle, beispielsweise bef_spindel_aus oder alle_spindeln_aus berucksichtigt, wie sie in der Widerle- 
gungssequenz WS auftreten. 

In cfiesem BeispieHall kann der Fehler dadurch behoben werden, daB die Transitionsbedingung von dem Zustand 
6 in den Zustand 4 folgender Ausdruck in der Syntax beispielsweise einer Anweisungsliste AWL hinzugefugt wird: 
UN bef_spindel_aus; 
UN alle_spindeln_aus; 

fOr das modif izierte SPS-Programm SProg kann die formale Verif ikation FV jederzeit wiederholt werden. wodurch eine 
Uberprufung der Anderung leicht mOglich ist 

Zweltes Ausfuhrungsbeispiel 

Nach einer groben Darstellung des ersten Ausfuhrungsbeispiels wird nun in dem zweiten Ausfuhrungsbeispiel 
detailliert beschrieben, wie die formale Verif ikation FV durchgefuhrt wird. 

In diesem zweiten Ausfuhrungsbeispiel wird wiederum das SPS-Programm SProg mit einer Zustandsgraphenspra- 
che beschrieben. Dabei wird allgemein ein Zustandsgraphenprogramm fur eine speicherprogrammierbare Steuerung 
durch eine Graphengruppe reprasentiert. Eine Graphengappe enthait Qblicherweise eine beliebige Anzahl von 
Zustandsgraphen. Ein Zustandsgraph besteht aus Zustanden, wobei der Zustand mit Nummer 0 als Inrtialzustand aus- 
gezeichnet ist, und aus Transitioned 

Ein Zustand unrrfaBt Qblicherweise drei Aktionsabschnitte: 

Eingangsabschnitt, 
- zyMischer Abschnrtt, und 
Ausgangsabschnitt. 

Eine Transition beschreibt einen Zustandsubergang, der von einer Transitionsbedingung abhdngt. 

Graphisch werden, wie dies auch in Rg. 3 und in Rg. 6 ersichtlich ist. Zustande als Kreise dargestellt und Transrt- 
ionen als Kanten, eventuell mit den Karrten zugewiesenen Prioritdten. die frei vorgebbar sind. 

Den Kanten sind Qblicherweise Transitionsbedingungen zugeordnet, die beispielsweise in Form sog. Anweisungs- 
listen beschrieben sind. Ferner sind Aktionen, die in den Zustanden durchgefuhrt werden, Qblicherweise ebenfalls in 
Anweisungslisten formuliert, die im werteren als AWL-Code bezeichnet werden. 

Femer wetst ein Zustandsgraph Qblicherweise Graphengruppenattribute, Zustandsattrfcute sowie Transitionsattri- 
bute fur die einzelnen Variablen, die in dem SPS-Programm verwendet werden, auf. 

Zur Durchfuhrung der formalen Verifikation FV wird in einem ersten Schrrtt eine textuelle Representation des 
Zustandsgraphenprogramms von dem Rechner R eingelesen. Die textuelle Representation des Zustandsgraphenpro- 
gramms weist Qblicherweise folgende Abschnitte auf: 

1 . Diagnoseinformation, die Qblicherweise sog. Formaloperanden und einen Zustandsgraphenprogrammtyp sowie 
eine Speicheradresse enthait mit der angegeben wird, wo sich das Zustandsgraphenprogramm in dem Speicher 
des Rechners R befindet. Die Diagnoseinformation enthait Qblicherweise auch Variablen, (fie nicht in dem 
Zustandsgraphenprogramm verwendet werden. 

2. Beispielsweise eine Ausfuhrungsreihenfolge des Zustandsgraphen. 

3. AJIe Zustandsgraphen des Zustandsgraphenprogramms. wobei ein Zustandsgraph im wesentlichen folgende 
Struktur ublicherwase aufweist: 
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Graphenattribute, beispielsweise einen Graphennamen und/oder eine Graphennummer, 

eine SchnrttstellendeWaration, die beispielsweise vom Benutzer dekiarierte Formaloperanden enthait, 

einen Uberwachungsabschnitt, der beispielsweise in AWL-Code vorliegt, 

- die Zustande des jeweiligen Zustandsgraphen, wobei jeweils ein Zustand folgende Struktur aufweist: 

- Zustandsattribute, z. B. Zustandsnummer, Sichtenattribut, Uberwachungszeit, Wartezeit, etc. 

~ den Eingangsabschnrtt d. h. Aktionen, die wdhrend des Eingangsabschnittes durchgefuhrt werden, bei- 
spielsweise formuliert wiederum in AWL-Code, 

- den zyklischen Abschnrtt, wobei die Aktionen wiederum in AWL-Code beschrieben sind, 

- den Ausgangsabschnrtt, wiederum formuliert in AWL-Code. 

Die Transrtionen des jeweiligen Zustandsgraphen, wobei eine Transition z. B. folgende Struktur aufweist: 

- Angabe des Ausgangszustandes der Transition und des Endzustandes der Transition, 

- eventuell beispielsweise eine Prioritdt, die der jeweiligen Transition zugeordnet wird, 

- Transitionsattribute, beispielsweise eine Wartezeitflagge, etc, 

- eine Transrtionsbedingung, die beispielsweise ebenfalls in AWL-Code formuliert isl 

- Einen Veniegelungsabschnitt, der ebenfalls beispielsweise in AWL-Code vorliegt. 
In Fig. 6 ist der Zustandsgraph des zweiten Ausfuhrungsbeispiel dargestellt 

Mit dem SPS-Programm SProg wird folgende beispielhaft dargestellte Situation beschrieben. Nach Aniauf, d. h. 
nach Initialisierung INIT, wird im ersten Zustand 0 auf das Werkstuck W gewartet, welches beispielsweise einem mit 
einer Lichtschranke LS begrenzten Gebiet zugefuhrt wird. 

Wird das Werkstuck W dem Gebiet zugefOhrt, wobei die Lichtschranke LS unterbrochen wird, erfolgt eine Transit- 
ion zu dem zweiten Zustand 1 , in dem in diesem Beispieffall ein Motor gestoppt wird, mit dem das Werkstuck W bewegt 
wird. Femer wird eine Hupe aktiviert, wodurch ein Laut ertOnt 

Der Laut ertOnt solange, bis eine Lichtschrankentaste aktiviert wird, wodurch (fie Transition in einem dritten 
Zustand 2 erfolgt, in dem der Motor wiederum gestartet wird und das Werkstuck W aus dem Lichtweg der Licht- 
schranke LS heraus bewegt wird. Ist das Werkstuck W aus dem Lichtweg der Lichtschranke LS heraus, d. h. ist die 
Lichtschranke LS wieder geschlossen, so geht das SPS-Programm SProg wieder in den ersten Zustand 0 uber, und 
wartet auf ein werteres Werkstuck W Ferner wird in dem dritten Zustand 2 das Werkstuck W weitergeleitet zu einer 
beliebigen Werterverarbertung. 

Ein Auszug aus der textuellen Beschreibung dieses Zustandsgraphenprogramms, also ein Be spiel eines Diagno- 
seinformationsteils, welches in Fig. 6 dargestellt ist wird im folgenden gegeben: 
STATED I AG RAM LICHTSCHRANKE 1 

SUPERVISION 
END_SUPERVISION 

STATE 1 
LABEL 

Werkstueck eingetroffen 

END^LABEL 

NORMAL 

ENTRYACTION 

S LICHT; 

S STOPMOTOR; 

END_ENTRY_ACTION 

CYCLIC_ACTION 

U HUPE; 

= HORN; 

END_CYCLIC_ACTION 

EXIT_ACTION 

R HORN; 

END_EXITACTION 
END_STATE 

TRANSITION FROM 1 TO 2 
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LABEL 

taster an 

ENDLABEL 

PRIORITY 1 NORMAL 

TRANSITION_CONDITION 

U LICHTSCHRANKETASTER; 

END_TRANSITION_CONDITION 

END_TRANSITION 

STATE 2 

LABEL 

Werkstueckwerterlerten 

END_LABEL 

NORMAL 

ENTRY_ACTION 

S STARTMOTOR; 

END_ENTRY_ACTION 

EXIT_ACTION 

R LICHT; 

END_EXIT_ACTION 
END_STATE 

INTERLOCK 
ENDJNTERLOCK 

Das SPS-Programm SProg wird auf mindestens einen endlichen Automaten abgebildet 701 (vgl. Fig. 7). 

Zur eirtfacheren Darstellung wird in dem zweiten Ausfuhrungsbeispiel im weiteren lediglich die ErmrtHung der 
Beschreibung der Transitionsrelation fur den endlichen Automaten von dem zweiten Zustand 1 zu dem dritten Zustand 
2 erldutert 

Dieses prinzipielle Vorgehen ist jedoch auf alle weiteren Transition en und Variablen, wie im weiteren eriautert wird, 
entsprechend anzuwenden und zu berucksichtigen. 

Beispielsweise werden in einem ersten Schritt Modellierungsvariablen zur Beschreibung des Teils der operationa- 
len Semantik des SPS-Programms SProg, der implizit in der Programmiersprache festgelegt sind. aber nicht explizit 
durch Programm-variable dargestellt wird, aus der Diagnoseirtformation und der SchnrttstellendekJaration ermittelt Fur 
das zweite Ausfuhrungsbeispiel wurden beispielsweise folgende Modellierungsvariablen eingefugt: 

[intemaJ,system t currerrt_9d] 

vaitnrtemal,system,current_sdJ,state,enum(['Reading of Process- Variables' = [0,0,0], Writing of Process- 
Variables^ [0,0, 1],TJCHTSCHRANKE' = [0,1,0], BAND' = [0,1,1], STATION2' = [1 ,0,0], 'STATION V = 
[1,0,1], STATION3' = 

[1 . 1 ,0]]),[current_sd1 ,current_sd2,current_sd3D, 

dient zur Beschreibung des Zustandsgraphen, in dem sich gerade die Programrnkorrtrdle befindet 

• [internaI,system ( 2G_NAME,current_state] 
vaitpntemal.system/LICHTSCHRANKE'.current.slatel.s tate,enum([T = [O.l],^' = [LOID' = [0,0]]). 
rLICHTSCHRANKEcurrent_state1 7LI C HTSCH RAN KEcurrent_ stateOD 

dient zur Beschreibung des Zustandsgraphen-Zustandes, in dem sich gerade die Programmkontrolle befindet 
[intemal,system,ZG_NAME > last_state] 

var(Ontemal,system;LICHTSCHRANKEMast.state],stat e,enum([T = [0.1 J,^ = [I.OLXT = 
[0,0MLICHTSCHRANKEIast_state1 VLICHTSCHRANKEIas t_state01), 

dient zur Beschreibung des Zustandsgraphen-Zustandes, verschieden vom aktuellen Zustand, in dem sich die Pro- 
grammkontrolle zuletzt befunden hat 

• [internal,system,ZG_NAME,state_change] 
N^it[intemal,system:LIChfrSCHRANKE'.state_.change] ( state,b oolean,rLICHTSCHRANKEstate_change_OD. 
dient zur Angabe, ob die Programmkontrolle im PLC-ZyWus zuvor in einem anderen Zustandsgraphen-Zustand 
gewesen ist, also, ob gerade eine Zustandsdnderung eingetreten ist 

• [intemal,system,ZG_NAME,wait_time_expired] 
var(nnternal,system,^ICHTSCHRANKE\wait.time_expired],st ate,boo- 
lean,rLICHTSCHRANKEwaitJime_expired_OT), 

dient zur Abstraktion vom Wartezeitattribut 

• [intemal,system,global_init_flag] 
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var([intemaI,system,globaUnrtJ^ 

dient zur Angabe, ob sich das Programm in der Initialisierungsphase bef indet Oder nicht 
• pnternal,system,onetf Input] 

wird for Abstraktionen verwendet (s. u.) Modus 1st 

1 input'. Typ ist struct von Boolean. GrOBe von struct ist gleich Anzahl der Abstraktionen. 

Mit jnternal.systenT wird angegeben, daB es sich bei der Variable urn eine (System-) Modellierungsvariable han- 
dett, die nicht Bestandteil des SPS-Programms SProg ist. 

Unter Verwendung der Modellierungsvariablen werden wie im werteren beschrieben, iterativ fur jede Transition des 
jeweiligen Zustandsgraphen eine Transition des endlichen Automaten unter Berucksichtigung der betroffenen Aus- 
gangszustande und Zielzustande der jeweiligen Transition gebildet 

Zusatzlich wird fur jeden Zustand des Zustandsgraphen eine Transition des endlichen Automaten fur den Fall gebil- 
det, daB keine von dem jeweiligen Zustand abgehende Transitionsbecfingung erfultt ist und somit im selben Zustand 
verblieben wird. 

AnschlieBend werden die Modellierungsvariablen vollstandig in dem Format des endlichen Automaten beschrie- 
ben, da nunmehr die Information Qber die Werte beispielsweise des Graphennamen oder der Zustandsnummer vor- 
liegt, von denen Typen der meisten Modellierungsvariablen abhangen, die im werteren beschrieben werden. 

Es hat sich als vorteilhaft herausgestelrt, fur eine Modellierungsvariable pjrrent_sd~ ihren Aufzahlungstyp urn 
zwei Werte zu erweitern, "Reading of Process Variables" und "Writing of Process Variables" . Hat die Variable 
currerrt_sd einen ersten Wert "Reading of Process Variables", so wird eine nichtdeterministische Transition des endli- 
chen Automaten gebildet, mit der alle Variablen des endlichen Automaten, die auf Eingangsadressen des endlichen 
Automaten gelegt sind, beliebig verandert werden, wahrend alle anderen Variablen des endlichen Automaten mit Aus- 
nahme der Modellierungsvariablen current_sd und einer global en Variable global jnitjlag unverandert bletben. 

Im weiteren werden Variablen des endlichen Automaten als FSM-Variablen (FSM=Finite State Machine) bezeich- 
net Hat die Variable currerrt_sd einen zweiten Wert "Writing of Process Variables", so wird im Automaten beschrieben, 
daB alle FSM-Variablen unverandert bleiben und nur die Model (variable current_sd auf den Wert "Reading of Process 
Variables" geandert wird. 

Ferner hat es sich als vorteilhaft herausgestelrt, daB pro Zustandsgraph zusatzlich fur eine Globalinrtialisierung des 
Zustandsgraphenprogramms jeweils eine Transition des endlichen Automaten gebildet wird. 
Eine Transition des endlichen Automaten wird im weiteren als FSM-Transrtion bezeichnet 
In einem werteren Verfahrensschritt werden VariaWenmodi, Variablentypen und BDD-Variablennamen fur Formal- 
operanden ermrtteft. 

Im werteren wird ein einfaches BeispieJ fur diese Vorgehensweise dargestelrt, die fur alle werteren Elemente des 
SPS-Programms SProg ebenso durchgefuhrt wird. 

In dem oben beschriebenen Diagnoseinformationsteil ist folgende Zeile zu finden: LJchtschranke 1 Hupe BOOL 
E0.1 Aus dieser Zeile wird fur den endlichen Automaten folgende FSM-Variable gebildet: var(pnternal,"LICHT- 
SCHRANKE","HUPE"l, state, bit, rE_0.1D 

Allgemein werden folgende Schritte bei der Bestimmung der Variablenmodi, der Variablentypen und der BDD- 
Variablennamen durchgefuhrt: 

- ein FSM-Variablenname wird aus den Parametern internal, dem Zustandsgraphennamen und dem Formaloperan- 
dennamen gebildet 

- Ein Variablenmodus des endlichen Automaten wird der Wert state zugewiesen. 

- Ein Variablentyp des endlichen Automaten, im werteren als FSM-Variablentyp bezeichnet, ergibt sich aus dem 
Zustandsgraphentyp, beispielsweise wird aus dem Zustandsgraphentyp Bool der FSM-Variablentyp Bit aus dem 
Zustandsgraphentyp Byte ein FSM-Variablentyp 8-Brt-Array, etc. 

- Eine Anzahl bendtigter BDD-Variablen des endlichen Automaten, im werteren als FSM- BDD- Variable bezeichnet, 
ergibt sich aus dem generierten FSM-Variablentyp. In dem obigen Betspiel entspricht des genau einer BDD-Varia- 
ble. 

- Ein Name der FSM-BDD-Variablen ergibt sich aus Adressbrts, auf die der Formaloperand abgebildet wird. Im obi- 
gen Beispiel ist der BDD-Variablenname "E_0.1". 

Ferner ist es vorteilhaft, Spezrfikationen von im Zustandsgraphenprogramm aufgerufenen Funktion zu berucksich- 
tigen. 

Diese Spezrfikationen sagen aus, welche Formaloperanden von der aufgerufenen Funktion verandert werden und 
auf welche Weise die Formaloperanden verandert werden. 

Der Funktionsaufruf wird. wie im weiteren beschrieben wird, wie alle anderen AWL-Befehle bearbeitet Fehht eine 
explizrte Spezifikation, wird implizit angenommen, daB genau die aufgerufenen Aktualparameter beliebig verandert 
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werden kOnnen, was unter Verwendung von im weiteren beschriebenen Abstraktionen realisiert wird. 

Ferner ist es ebenso vorteilhaft, Spezif ikationen von Umgebungsdnderungen zu berucksichtigen. Diese Spezif ika- 
tionen sagen aus, welche Formaloperanden von der Umgebung verdndert werden und auf welche Weise sie verdndert 
werden. Dabei ist es vorteilhaft, nur Formaloperanden zu berucksichtigen, die von dem Zustandsgraphenprogramm 
gelesen aber nicht beschrieben werden. Fehtt eine explizite Spezifikation, wird implizit angenommen, daB (fie Umge- 
bung alle Leseformaloperanden beliebig verflndern kann. Dies wird durch cfie Modellvariable current_sd mit dem Wert 
"Reading of Process Variables" modelliert 

Abstraktionen werden bendtigt, werm konkrete Werte unbekannt sind Oder der Wertebereich einer Variabien 
unendlich ist Abstraktionen sind beispielsweise erfordertich bei der Beschreibung einer Wartezeit, einer Uberwa- 
chungszert, allgemein bei Zeitfunktionen, bei Zdhtfunktionen, bei Spezif ikationen und beispielsweise bei einem fehlen- 
den Initialwert in verschiedenen Kontexten, z. B. bei einer Zuweisung eines nichtinitialisierten Registerwertes. 

Eine Abstraktion von einer Variabien v ist beispielsweise die Zuweisung einer frei vorgebbaren Komponente k von 
neoflnput (vgl. oben) in einer FSM-Transition. 

Die entsprechende TeiHbrmel einer im weiteren beschriebenen FSM-Transrtionsrelation kGnnte dann sein: next 
(v)=[internal, system, oneof Input].. k oder anstelle der Variabien v in einem Teilausdruck einer FSM-Transition die 
RerOcksichtigung der Komponente k, also beispielsweise anstatt next (w)=v wurde sich ergeben: next (w) = [internal, 
system, oneof Input].. k. 

Ferner ist es vorgesehen, eine Inrtialzustandsmenge des endlichen Automaten, die im weiteren als FSM-lnitialzu- 
standsmenge bezeichnet wird, zu ermrtteln. Dabei werden alle Modellierungsvariablen festgelegt Einem Formaloper- 
anden ZFEHLER wird der Wert false zugewiesen, alle Leseformaloperanden sind unten spezrf iziert und den Bits aller 
sonstigen Formaloperanden wird der Wert false zugewiesen. 

Femer werden folgende Werte in der Initialzustandsmenge zugewiesen: 



1 . current_sd auf den ersten ZG der Ausfuhrungsreihenfblge 

2. alle current_state und last_state auf den fest vorgegebenen Initialzustand 0 

3. alle wait_time_expired und Z FEHLER auf false 

4. gtobal_init Jlag auf true 

[intemal 1 system,cunrent_sd] = 'LICHTSCHRANKE' a (true a 
[irtemal,system;LICHTSCHRANKE\current_statel = '0' a 
[intemal.system/LICHTSCHRANKEMast.state] = '0' a 
[internal.system/LICHTSCHRANKE'.state.change] = true a 
[imemal,system,^ICITrSCHRANKE\wartJime_expired] = false a 
pnternal/LICHTSCHRANKE', , Z_FEHLERl = false a 
pntemal,system,'BAND\currerrt_state] = '0' a 
[internaI,system;BAND',last_state] = '0' a 
[internal l system, , BAND , ,state_change] = true a 
nntemal,system,'BAND , ,wait_time_expired] = false a 
tintemal/BAND , ,'Z_FEHLERl = false a 
[internal,system;STATION2',cunrent_state] = XT a 
[internal,system/STATION2Mast_state] = '0' a 
[internaI,system;STATION2',state_change] = true a 
[irternal ( system, , STATION2 , ,wait_time_expired] = false a 
prtema!/STATION2\ , Z_FEHLERl = false a 
[intemal,system;STATIONr,cunrent_state] = XT a 
[intemal.system/STATIONIMasLstate] = '0* a 
[intemal,system;STATIONr,state_change] = true a 
nrtemal,system/STATIONr,wait_time_expiredI = false a 
pmernal,'STATlON1\'Z_FEHLERl = false a 
[internal.system/STATIONa'.current.state] = '0' a 
[intemal ( system:STATION3Mast_state] = '0' a 
[internal,system;STATION3',state_change] = tru a 
[irtemal,system;STATION3\waitJime_expired] = false a 
pntemal/STATION^^.FEHLERl = false) a true a true a 
true a [intemal,system,global_inrt_flag] = true a 
£lle restlichen Formaloperanden- Brts bis auf M_4.0 (BA_HAND) 
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auf false' 

Weiterhin wind eine Transitionsrelation des endlichen Automaten, die im werteren als FSM-Transrtionsrelation 
bezeichnet wird, ermittelt. 

Diese wird sowohl fur eine Initialisieaingsphase als auch fur eine Laufzeitphase ermittelt Im werteren wird jedoch 
ledigtich die Ermittlung der FSM-Transrtionsrelation for die Laufzeitphase beschrieben, da diese in der Initialisierungs- 
phase entsprechend durchgefGhrt wird mit dem Unterschied, daB die giobale Modellierungsvariable globaljnitjlag der 
Wert true zugewiesen wird. 

Ansonsten ist die Ermittlung der FSM-TransitionsreJation for (fie Initialisierungsphase prinzipiell identisch mit der fur 
die Laufzeitphase. 

Die Berechnung der FSM-Transrtionsrelation wird beispielhaft an der Transition des zweiten Ausfuhrungsbeispiels 
von dem zweiten Zustand 1 zu dem dritten Zustand 2 dargestellt. 
Folgende Abschnrtte und Attribute werden symbolisch evaluiert: 

1 . Uberwachungsabschnitt des zweiten Zustands 1 , 

2. Transrtionsbedingung von dem zweiten Zustand 1 zu dem dritten Zustand 2; 

3. ZykJischer Abschnrtt des zweiten Zustandes 1 ; 

4. Austrittsabschnitt des zweiten Zustandes 1 ; 

5. Eingangsabschnrtt des dritten Zustandes 2; 

6. zyWische Abschnitte des dritten Zustandes 2; 

7. Veniegelungsabschnitt des zweiten Zustandes 1 . 

Die Evaluierung der einzelnen Abschnitte erfolgt beispielsweise durch sukzessives Evaluieren der einzelnen AWL- 
Befehle, in denen die symbolische Wirkung der einzelnen Befehle in Abhangigkert vorangegangener Befehle ermittelt 
wird. Die Evaluierung zweier aufeinanderfolgender Abschnitte ergibt sich analog. 

Im fotgenden werden zwei Beispiel fur die Evaluierung des Befehls JU HUPE" und des Befehls JHORN* darge- 
stellt: 

Der Befehl U HUPE" hat Wirkung auf ein internes Register VKE, das keine FSM-Variable ist: 

- neu(VKE) - HUPE a VKE 

Der Befehl JHORN* hat folgende Wirkung: 

- neu(HORN) = VKE) a neu(VKE) = VKE 

Weiterhin wird im folgenden beispielhaft die Evaluierung mehrerer Befehle an dem Eingangsabschnrtts des zwei- 
ten Zustands 1 dargestellt: 



CYCLIC ACTION 



{VKE = true} 

U HUPE; 

{neu (VKE) = HUPE a true 

= HORN; 

{(neu (VKE) = HUPE a true) a 
(neu (HORN) = HUPE a true)} 

END CYCLIC ACTION 



hat die Wirkung: 
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neu(HORN) = HUPE 

Dieser oben beschriebene Abschnrtt wird in eine Darstellung des endlichen Automaten ohne BDDs abgebildet 
Dabei hat beispielsweise das interne Format des ndlichen Automaten folgende Struktur: 

1. Projektname (1. Zeile) 

2. Einen Abschnitt mit foigender zyklischer Struktur, durch den jeweils (fie FSM-Transitionen pradikatenlogisch 
reprdsentiert werden: 

Ein Name des Zustandsgraphen sdName, 

- eine LJste von FSM-VariaWen, die nicht von dem Zustandsgraphen ve&ndert werden, die als SDstable 
bezeichnet werden, 

- optionale. fur das Verfahren unbedeutende Parameter startprio, statechange, statenumber, 

- eine LJste von FSM-VariaWen, die von einer im werteren naher beschriebenen FSM-Transition nicht verandert 
werden, bezeichnet mit transstabJe, 

- eine prfldikatenlogische Transitionsbedingung cond Formula, 

- eine pradikatenlogische Formel uber die Wertanderung der FSM-VariaWen in dieser Transition, bezeichnet als 
next Formula. 

3. Einen Abschnrtt uber einen Teil des endlichen Automaten im FSM-Format, der symbolische Informationen ent- 
haft, die nicht in einem BDD-Format vorliegen. Enthalten sind in diesem Abschnitt beispielsweise ein Name des 
endlichen Automaten FSMname, symbolische Namen for BDD-Variablen fsmArgs, eine Liste der Reihenfolge der 
symbolischen Namen der BDD-Variablen, IsmOrder, eine Liste von abgeleiteten VariaWentypen fQr den jeweiligen 
endlichen Automaten zusammen mit der jeweiligen Definition des VariaWentyps fsmTypDefs, eine Liste fsmVars 
aller FSM-Variablen des endlichen Automaten, sowie eine Angabe einer hierarchischen Struktur der FSM-Varia- 
Wen fsmstructure, der jedoch fur die Erfindung unwesentlich ist 

Fur die betspielhaft dargestelrte Transition ergibt sich folgende FSM-Transition in dem internen Format: 
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sdStable ( 



[ [internal, 


•BAND', 'BAND' ] , 


[internal. 


' BAND ' , ' BA_HAND ' ] , 


[internal, 


'BAND', ' Z_ 


FEHLER ' ] , 


[internal, 


' LICHTSCHRANKE ' , ' BA_HAND ' ] , 


[internal, 


* LICHTSCHRANKE ' , ' HUPE ' ] , 


[internal, 


1 LICHTSCHRANKE ' , 1 LICHTSCHRANKE ' ] , 


~ [internal, 


' LICHTSCHRANKE ' , ' LICHTSCHRANKETASTER ' ] , 


[internal, 


' STATION1 • 


, ' BA_HAND' ] , 


[internal, 


' STATION1 ' 


, 'BERO'], 


[internal, 


' STATION1 ' 


, ' LAMPE ' ] , 


[internal, 


'STATION1' 


, 'TASTER']/ 


[internal, 


' STATION1 ' 


, ' Z_FEHLER* ] , 


[internal, 


' STATION2 ' 


, 'BA_HAND* ] , 


[internal, 


' STATION2 ' 


, 'BERO'], 


[internal, 


' STATION2 ' 


, 'LAMPE'], 


[internal, 


* STATION2 ' 


, 'TASTER'], 


[internal, 


' STATION2 * 


, 'Z_FEHLER' ] , 


[internal, 


' STATION3 * 


, ' BA_HAND * ] , 


[internal, 


' STATION3' 


, 'BERO'], 


[internal, 


' STATION3 ' 


, 'LAMPE'], 


[internal, 


' STATION3* 


, 'TASTER'] , 
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[internal, STATIONS' , ' Z_FEHLER' ] , 
t internal , system, 'RAND 1 , current_state] , 
[internal, system, •BAND 1 , last_state] , 
[ internal , system, 1 BAND ' , s tate_change ] , 
[internal, system, 'BAND 1 , wait_time_expired] , 
[internal, system, f STATION1 ' , curren t_state] , 
[internal, system, 'STATION1' , last_state] , 
[internal, system, • STATION1 1 , state_change] , 
[internal, system, 1 STATION1 1 , wait_time_expired] , 
[internal, system, , STATION2 f , current_state] , 
[internal, system, • STATION2 f , last_state] , 
[internal, system, ' STATION2 f , state_change] , 
[internal, system, f STATION2 ' , wait_time_expired] , 
[internal, system, 'STATIONS' , curren t_state] , 
[internal, system, ' STATION3' , last_state] , 
[internal, system, 'STATIONS' , state_change] , 
[internal, system, ' STATION3 ' , wait_time_expired] , 
[internal, system, global_init_f lag] ] 
) . 



stateNumber(T). 

transStable ( 

[[internal, 'BAND', 'MOTOR_STOP' ] , 
[ internal , ' LICHTSCHRANKE ' , ' LICHT ' ] , 
[internal, 'LICHTSCHRANKE' , 'STOPMOTOR' ] , 
[internal, ' STATION1 ' , ' STOPMOTOR' ] , 
[internal, ' STATION2' , 'STOPMOTOR' ] , 
[internal, ' STATION3 ' , 'STOPMOTOR' ] ] 

) . 



condFormula([internaI.system,current_sd] = 'LICHTSCHRANKE' a 
pmernal.system/LICHTSCHRANKE'.current.state] = Ta- 
prternal,system ( gtobaljnitjlag] a 

(prternal/UCHTSCHI^NKE\ , LICHTSCHRANKETASTERl a ite(~ 
prternal/LICHTSCHRANKEVSTOPJWVIT™ 
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nextFormula ( 

[ [ [internal, ' LICHTSCHRANKE ' , ' STARTMOTOR' ] , true] , 
[ [internal, 'BAND' , * MOTOR_START ' ] , true] , 
[ [internal, ' STATION2 ■ , ' S TARTMOTOR ' ] , true] , 
[ [internal, 'STATION1 ' , ' STARTMOTOR' ] , true] , 
[ [internal, ' STATION3 ' , ' STARTMOTOR* ] , true] , 
[ [internal, * LICHTSCHRANKE ' , 'HORN* ] , false] , 
[[internal, 'LICHTSCHRANKE', ' Z_FEHLER' ] , false] , 

[ [internal, system, 'LICHTSCHRANKE' ,wait_time_expired] , false] , 
[ [internal, system, ' LICHTSCHRANKE ' , last_state] , ' 1 ' ] , 
[ [internal, system, » LICHTSCHRANKE *, current s tate ] , '2'], 
[ [internal, system, 'LICHTSCHRANKE' , state_change] , true] , 
[ [internal, system, current_sd] , 'BAND' ] ] 
) . 



AnschlieSend wind die FSM-Transition aus der intemen Darstellung in eine rein logische Fbrmeldarstellung uber- 
fuhrt, wobei aus 



V 
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sdStable ( 

5 [ [internal, 'BAND' , 'BAND' ] , 

[internal, 'BAND' , 'BA_HAND' ] , 
w [internal, ' BAND' , ' Z_FEHLER' ] , 

[internal, ' LICHTSCHRANKE' , ' BA_HAND' ] , 
,5 [internal, ' LICHTSCHRANKE' , ' HUPE' ] , 

[internal, ' LICHTSCHRANKE' , ' LICHTSCHRANKE' ] , 
20 [internal, ' LICHTSCHRANKE' , ' LICHTSCHRANKETASTER' ] , 

[internal, ' STATION1' , ' BA_HAND' ] , 
25 [internal, ' STATION1' , ' BERO' ] , 

[internal, ' STATION1' , ' LAMPE' ] , 



55 
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[internal, ' STATION]/ , ' TASTER' ] , 

[internal, ' STATION1' , 9 Z_FEHLER' ] , 

[internal, 'STATION2' , 'BA_HAND' ] , 

[internal, 'STATION2' , 'BERO' ] , 

[internal, 'STATION2' , ' LAMPE' ] , 

[internal, ' STATION2' , ' TASTER' ] , 

[internal, 9 STATION2' , ' Z_FEHLER' ] , 

[internal, 9 STATION3' , 9 RA__HAND' ] , 

[internal, ' STATION3' , 9 BERO' ] , 

[internal, 'STATION3' , ' LAMPE' ] , 

[internal, ' STATION3' , ' TASTER' ] , 

[internal, ' STATION3' , ' Z_FEHLER' ] , 

[internal, system, 'BAND' ,current_state] , 

[internal, system, ' BAND' , las testate] , 

[internal, system, 'BAND' ,state_change] , 

[internal, system, ' BAND' , wait_time_expired] , 

[internal, system, ' STATION1' , current_state] , 

[internal, system, 9 STATION1' , last_state] , 

[internal, system, ' STATION1' , state_change] , 

[internal, system, ' STATION1' , wait_time_expired] , 

[internal, system, ' STATION2' , current_state] , 

[internal, system, 'STATION2' ,last_state] , 
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[internal, system, ' STATION2 r , s tat exchange] , 
[internal, system, ' STATION2' , wait_time_expired] , 
[internal, system, ' STATION3' , current_state] , 
[internal, system, ' STATION3' , last_state] , 
[internal, system, 9 STATION3' , state__change] , 
[internal, system, ' STATION3' , wait_time_expired] , 
[internal, system, global_init_f lag] ] 

) . 

startPrio((1 , 0)). 

stateChangeflinternal.system, LICHTSCHRANKE r ,state_change] ( tr ue,felse). 
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stateNumber(globalinit). 

transStable ( 

[ [internal, 'BAND' , ' MOTOR_START ' ] , 
[internal, 'BAND' , 'MOTOR_STOP f ] , 
[internal, 'LICHTSCHRANKE' , 'HORN' ] , 
[internal, 'LICHTSCHRANKE' , 'LICHT' ] , 
[internal, ' LICHTSCHRANKE' , ' STARTMOTOR' ] , 
[internal, ' LICHTSCHRANKE' , ' STOPMOTOR' ] , 
[internal, ' STATION1' , ' STARTMOTOR' ] , 
[internal, ' STATION1' , ' STOPMOTOR' ] , 
[internal, ' STATION2' , ' STARTMOTOR' ] , 



[internal, ' STATION2' , ' STOPMOTOR' ] , 
[ internal, ' STATION3' , ' STARTMOTOR' ] , 
[internal, 'STAT ION3' , 'STOPMOTOR' ] ] 

) . 

condFormula([intemal,system,current_sd] = ' LI CHTSCH RAN KE ' A [i nternal , system, global_init_f lag]) . 
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nextFormula ( 

[ [ [internal, system, ' LICHTSCHRANKE' , last_state] , tint 
ernal, system, ' LICHTSCHRANKE' , current_state] ] , 

[ [internal, system, ' LICHTSCHRANKE' , current_state] , ' 0 
'], 

[ [internal, system, 'LICHTSCHRANKE' , state_change] , tru 
e], 

[ [internal, ' LICHTSCHRANKE' , ' Z_FEHLER' ] , false] , 

[ [internal, system, 'LICHTSCHRANKE' , wait_time_expired 
1 , false] , 

[ [internal, system, currentsd] , 'BAND' ] ] 



wind: 

next ( [ internal , ' BAND' , ' BAND' ] ) = [ internal , ' BAND' , ' BAND' ] a 
next ( [internal, ' BAND' , ' BA_HAND' ] ) = 

[ internal , ' BAND' , ' BA_HAND' ] A 
next ( [internal, ' BAND' , ' Z_FEHLER' ] ) = [internal, ' BAND' , ' Z_FEHLER 

Ma 

next ( [internal, ' LICHTSCHRANKE' , ' BA_HAND' ] ) = [internal, ' LICHTSC 
HRANKE' , ' BA HAND' ] A 
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next ( [internal, ' LICHTSCHRANKE' , ' HUPE' ] ) = [internal, ' LICHTSCHRA 

NKE','HUPE'] A 
next ( [internal, ' LICHTSCHRANKE' , ' LICHTSCHRANKE' ] ) = 
[internal, 'LICHTSCHRANKE' ,' LICHTSCHRANKE' ] a 
next ( [internal, ' LICHTSCHRANKE' , ' LICHTSCHRANKETASTER' ] ) = 
[internal, ' LICHTSCHRANKE' , 'LICHTSCHRANKETASTER' ] A 
next ( [internal, 'STATION1' , 'BA_HAND' ] ) = 
[internal, ' STATIONl' ,' BAJ1AND' ] a 
next ( [ internal , ' STATIONl 9 , ' BERO' ] ) = 
[internal, ' STATION1' , ' BERO' ] a 
next ( [internal, [ STATIONl' , ' LAMPE' ] ) = 
[internal,' STATIONl' ,'LAMPE'] a 
next ( [internal, ' STATIONl' , ' TASTER' ] ) = 
[internal, 'STATIONl' , 'TASTER' ] a 
next ( [internal, ' STATIONl' , ' Z_FEHLER' ] ) = 
[ internal , ' STATIONl ' , ' Z_FEHLER' ] a 
next ( [internal, ' STATION2' , ' BA_HAND' ] ) = 
[internal, 'STATION2' , 'BA_HAND' ] a 
next ( [internal, ' STATI0N2' , 'BERO' ] ) = 
[internal, ' STATION2' , ' BERO' ] a 
next ( [internal, ' STATION2' , ' LAMPE' ] ) = 
[internal, 'STATION2 ','LAMPE'] a 
next ( [internal, ' STATION2' , ' TASTER' ] ) = 
[internal, 'STATION2' , 'TASTER' ] a 
next ( [ internal, ' STATI0N2' , ' Z_FEHLER' ] ) = 
[internal, ' STATION2' , ' Z_FEHLER' ] a 
next( [internal, 'STATION3' , ' BA_HAND' ] ) = 
[internal, 'STATION3' , 'BA_HAND' ] a 
next ( [internal, 'STATI0N3' , 'BERO' ] )= 
[ internal, 'STATION3', 'BERO'] a 
next ( [internal, 'STATION3' , ' LAMPE' ] ) = 
[internal, 'STATION3' , 'LAMPE' ] a 
next ( [internal, ' STATION3' , ' TASTER' ] ) = 
[internal, ' STATION3' , ' TASTER' ] a 
next ( [internal, ' STATION3' , ' Z_FEHLER' ] ) = 
[internal, ' STATION3' , ' Z_FEHLER' ] a 
next ( [internal, system, ' BAND' , current_state] ) = 



EP 0 828 215 A1 



[internal/ system, 'BAND' , curr en t_state] a 

next ( [internal, system, ' BAND' , last_state] ) = 

[internal, system, 'BAND' , last_state] a 

next ( [internal, system, 'BAND' , state_change] )= 

[ internal , system, ' BAND' , s tat exchange ] a 

next ( [internal, system, ' BAND' , wait_time_expAred] ) = 

[internal, system, 'BAND' , wait_time_expired] a 

next( [internal, system, 'STATION1' , current_state] )= 

[internal, system, ' STATI0N1' , current_state] a 

next ( [internal, system, ' STATION1' , last_state] ) = 

[internal, system, ' STATION1' , last_state] a 

next ( [internal, system, ' STATION1' , state_change] ) = 

[internal, system, ' STATION1' , state_change] a 

next ( [internal, system, ' STATION1' , wait_time_expired] ) = 

[internal, system, ' STATION1' , wait_time_expired] a 

next ( [internal, system, ' STATION2' , current_state] ) = 

[internal, system, ' STATION2' , curr en testate] a 

next ( [internal, system, ' STATION2' , last_state] ) = 

[internal, system, ' STATION2' , last_state] a 

next ( [internal, system, ' STATION2' , state_change] ) = 

[internal, system, ' STATI0N2' , state_change] a 

next ( [internal, system, 'STATION2' ,wait_time_expired] ) = 

[internal, system, ' STATION2' , wait_time_expired] a 

next ( [internal, system, ' STATION3' , current_state] ) = [internal, sy 

stem, ' STATI0N3' , current_state] a 
next ( [internal, system, ' STATION3' , last_state] ) = [internal, syste 

m, 'STATION3',last_state] a 
next { [internal, system, ' STATION3' , state_change] ) = [internal, sys 

tern, 'STATION3', stat e_change] a 
next ( [internal, system, 'STATION3' , wait_time_expired] )= [interna 

1, system, ' STATION3' , wait_time_expired] a 
next ( [internal, system, global_init_f lag] ) = [internal, system, glo 

bal_init_f lag] a 

next ( [internal, 'BAND' , ' MOTOR_START ' ] )= 
[internal, 'BAND' , 'MOTOR_START' ] a 
next ( [ internal , ' BAND' , ' MOTOR STOP' ] ) = 
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[ internal , ' BAND' , ' MOTOR_STOP' ] a 
next ( [ internal , 9 LICHTSCHRANKE' , 'HORN' ] ) = 

[ internal , ' LICHTSCHRANKE' , 9 HORN' ] a 
next ( [internal, 'LICHTSCHRANKE' , 'LICHT' ] ) = 

f internal , 9 LICHTSCHRANKE' , ' LICHT' ] a 
next ( [internal, ' LICHTSCHRANKE ' , ' STARTMOTOR' ] ) = 

[internal, ' LICHTSCHRANKE' , ' STARTMOTOR' ] , a 
next ( [internal, ' LICHTSCHRANKE' , ' STOPMOTOR' ] ) = 

[internal, ' LICHTSCHRANKE' , 9 STOPMOTOR' ] a 
next ( [internal, ' STATION1' , ' STARTMOTOR' ] ) = 

[internal, ' STATION1' , ' STARTMOTOR' ] a 
next ( [internal, ' STATION1' , ' STOPMOTOR' ] ) = 

[internal, ' STATION1' , ' STOPMOTOR' ] a 

next ( [internal, ' STATION2' , ' STARTMOTOR' ] ) = 

[internal, ' STATION2' , ' STARTMOTOR' ] A 
next ( [internal, ' STATION2' , ' STOPMOTOR' ] ) = 

[ internal, 'STATION2',' STOPMOTOR'] a 

next ( [internal, ' STATION3' , ' STARTMOTOR' ] ) = 

[ internal, 'STATION3',' STARTMOTOR' ] a 
next ( [internal, ' STATION3' , ' STOPMOTOR' ] ) = 

[internal, ' STATION3' , ' STOPMOTOR' ] a 

[internal, system, current_sd] = 'LICHTSCHRANKE' a 
[internal, system, global_init_f lag] a 

next ( [internal, system, ' LICHTSCHRANKE' , last_state] ) = [ internal, 
system, ' LICHTSCHRANKE' , current_state] a 

next ( [internal, system, ' LICHTSCHRANKE' , current_state 
])='0'] A 

next ( [internal, system, ' LICHTSCHRANKE' , state_change] 
)=true] a 

next ( [internal, ' LICHTSCHRANKE' , ' Z_FEHLER' ] ) =f alse] 

A 

next ( [internal, system, 9 LICHTSCHRANKE' , wait_time_exp 
ired] )=false] a 
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next ( [internal, system, current sd] )='BAND' ] 



Dieses Verfahren wind fur alle Transitionsrelationen des endlichen Automaten durchgefuhrt Die logische Gesamt- 
formel fur die Transitionsrelation des endlichen Automaten ergibt sich aus der disjunktiven Verknupfung Qber alle logi- 
sche Formeln fQrdie einzelnen FSM-Transitionen. 

Somit liegt das SPS-Programm SProg in dem Rechner R in einer Darstellung des endlichen Automaten vor. 

AnschlieBend wird cfie logische Formel zur Beschreibung des endlichen Automaten in eine BDD-Darstellung uber- 
fuhrt 702 (vgl. Figur 7). 

Dies erfolgt beispielsweise nach dem in dem Dokumerrt [2] beschriebenen Verfahren. 

Die zu verifizierende Eigenschaft des nun in der BDD-Darstellung vortiegenden SPS-Programms wird in einem 
letzten Schrrtt 703 unter Verwendung der sog. symbolischen ModellGberprufung (Symbolic Model Checking) uberprQft 
Dies erfolgt beispielsweise nach dem in dem Dokumerrt [3] beschriebenen Verfahren. 

Drittes Ausfuhrungsbeispiel! 

Eine weitere MOglichkeit, ein SPS-Programm SProg darzustellen, ist in der Verwendung von Anweisungslisten 
(AWL) zu sehen. Das Verfahren kann ohne weiteres auch fur ein SPS-Programm SProg, welches in Form einer Anwei- 
sungsliste AWL vorliegt, durchgefuhrt werden. Clblicherweise besteht ein AWL-Programm aus einem Organisations- 
baustein OB und einem Programmbaustein PB. Der Programmbaustein PB wird zyWisch von dem 
Organisationsbaustein OB gestartet. 

Es haben sich verschiedene Mdglichkerten herausgesteltt, SPS-Programme SProg die in Form von Anweisungsli- 
sten vorliegen, zu verifizieren. 

Beispielsweise hat es sich in einer Weiterbildung des Verfahrens als vorteilhaft herausgesteltt, die Anweisungsliste 
auf eine Beschreibung in der Sprache VHDL abzubikJen. 

Die Verifikation wird dann bei dieser Weiterbildung des Verfahrens unter Verwendung der bekannten Verfahren zur 
Verifikation von Programme^ die in VHDL beschrieben sind, durchgefuhrt. Diese Verfahren sind beispielsweise in den 
Dokumenten [4], [5] und [6] beschrieben. 

Der Programmbaustein PB wird bei dieser Variante als ein VHDL-ProzeB modelliert, der auf ein von dem Organi- 
sationsbaustein OB zyktisch erzeugtes Startsignal sensitiv ist 

Der VHDL-ProzeB erhaft damit Eingabewerte, die zur steigenden Flanke des Startsignals aktuell sind. Ausgabe- 
werte werden dann jeweils nach einem Durchlauf des VHDL-Prozesses auf Ausgangsports geschrieben. 

Dieses Verhatten entspricht genau dem eines SPS-Programms SProg in Form von Anweisungslisten. Im Anlauf 
und im Anfang des zyWischen SPS-Programms werden die Signalzustande von Eingabebaugruppen zum ProzeBab- 
bild der Eingange ubertragen. Am Ende jedes SPS-ProgrammzyWus werden die Signalzustande von dem ProzeBab- 
bild der Ausgange zu den jeweiligen Ausgabebaugruppen transferiert 

Somit werden Eingange des SPS-Programms SProg zu Inputports des VHDL-Programms, Ausgange des SPS- 
Programms werden zu Outputports des VHDL-Programms. Ausgange, deren Wert auch wieder gelesen wird, werden 
zu sog. Bufferports. Merker kOnnen als interne Signale dektariert werden. Sollen die Merker von auBen beobachtbar 
sein, sind sie als sog. Bufferports zu deklarieren. 

Folgende Tabelle gibt eine Ubersicht der Abbildung der einzelnen Elemente des SPS-Programms in AWL-Darstel- 
lung und dem entsprechenden Element in der VHDL-Beschreibungssprache: 
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Steuerung 


Hardware 


Start des OB 


pos. Taktflanke 


Eingang 


Eingang 


Ausgang 


(Rip-Flop-)Ausgang 


Merker 


Latch 


Datenbit 


Latch 


Timer 


Peripheres Register 


Zahler 


Peripheres Register 



Die Umsetzung nach VHDL erfolgt z. B. nach dem Schema, das in der fblgenden Tabelle dargestelft ist: 



AWL 



VHDL 



OB 

Programm-, 
Funktionsbaustein 
Datenbaustein 
Eingang 
Ausgang 
Merker 

Akkumulator 1 
Akkumulator 2 

Verknttpfungsergebnis VKE Bit Variable 

S, R if (VKE = f l f ) then ... else 

Timer In-Port 



Process, sensitiv auf Signal K *clk ff 
Procedure 

variable DB array (0 to maxAdr) of Word; 
In-Port 
Buffer-Port 
Variable 
Word Variable 



Zahler 
Sprung 



In-Port 
Loop ♦ . . 



case PC 



Sprungbefehle sind lokal innerhalb eines Netzwerks. Im Rahmen einer KbntrollfluBanalyse (CFA) werden zunachst 
die BasisblOcke des Netzwerks bestimmt und diesen jeweils ein eindeutiger Wert des Programmzdhters zugeordnet. 
Ein Sprungbefehl wird auf beispielswetse folgende loop- und case-statements abgebildet: 
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Netzwerkl : loop 

wait on elk until elk = f l f ; 

case PC is 

when 0 => Basic Block 0; 

PC := newPC; 

exit; 

when 1 => Basic Block 1; 

PC := newPC; 

exit; 



when others => exit; 
end case; 

end loop Netzwerkl; 

Der Befehl „BEB" wird z. B. durch 
if (VKE = »l f ) then return; 

else PC := newPC; 

realisiert 

Vorwartssprunge sind unproblematisch und kdnnen auch durch geschachtelte Jf...then...else~-Ausdrijcke imple- 
mentiert werden. 

Zur Gewahrleistung, da8 auch bei Ruckwartssprungen die Existenz eines Schleifenfixpunktes gegeben ist, ist es 
vorteilhaft, daB zusdtzlich atternativ eineder foigenden MaBnahmen ergriffen wird: 

Die Datenworte werden als FSM-Variable modeiliert 
An jedem Schleifenbeginn wird foJgender Ausdruck zusdtzlich eingefugt: 
wait on elk until dk = T. 

Komplexe Funktionsbausteine, aber auch Timer und Zahler, kOnnen als Black Boxes modeiliert und darm ihre 
Funktion durch formal beschriebene Annahmen abstrahiert werden. Die Eingange des komplexen Funktionsbausteins 
(Timers, Zahlers, ...) werden dabei zu Ausgangen des SPS-Programms, die Ausgdnge dieses Bausteins werden dabei 
zu Eingangen des SPS-Programms. 

Hdufig wird die zu uberprufende Eigenschaft des SPS-Programms von der genauen Funktion des Bausteins 
(Timers, Zahlers, ...) unabhangig sein. Die symblische Modelluberprufung uberpruft dann die zu verrfizierende Eigen- 
schaft unter alien mOglichen Wertebelegungen dieser Baustein- (Timer-, Zahler-, ...) Ausgange. 

Da die Eingange -beispielsweise eines Timers- zu Ausgangen des SPS-Programms SProg werden, kann der Wert 
dieser Eingange unter Verwendung der symbolischen Modelluberprufung uberpruft werden. 

Falls die zu uberprufende Eigenschaft jedoch von der Funktion des Bausteins (Timers, Zahlers, ...) abhangt, kann 
das VerhaHen des Bausteins durch entsprechende Annahmen in abstrahierender Weise beschrieben werden. 

Gegebenenfalls kOnnen komplexe Funktionsbausteine (Timer, Zahler, ...) aber auch als eigene VHDL-Prozesse 
Oder VHDL-Komponenten modeiliert werden, die das Verhalten detailliert beschretben. 

Timer und Zahler werden dabei Ld.R. vordefiniert und in eine Bausteinbibliothek eingebracht werden. Sie sind 
dann bei der Umsetzung in den Automaten lediglich zu instanziieren. Komplexe Funktionsbausteine kOnnen wie regu- 
lare SPS-Programme automatisch ubersetzt werden. 

Ein Timer kann beispielsweise auf folgende Weise als VHDL-Komponente modeiliert werden: 
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library IEEE, DWARE, DW03; 
use IEEE. std_logic_1164. all; 
use DW03.DW03_coraponents.all; 



entity SETIMER is 

port( T : in std_logic; 
TCLK : in std_logic; 
R : in std_logic; 
Q : buffer std_logic; 

count : out std_logic_vector (2 downto 0) 
tercntl : out std_logic 

) ; 

end SETIMER; 



architecture fup of SETIMER is 
constant width: positive := 3; 
constant count_to: positive := 5; 



constant up : 
constant zero 



std_logic := f l f ; — upward 
std_logic_vector (2 downto 0) 



:= "000" 



signal up_dn : 

signal tercnt 

signal reset 

signal load 

signal RN 



std_logic := up; 
: std_logic; 
: std_logic:= f l f ; 
: std_logic : = * 0 1 ; 
: std logic; 



signal data : std_logic__ vector (2 downto 0) := "000"; 
begin 
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— component instantiation 
U0: DW03Jbictr_scnto 

5 generic map (width => width, 

count_to => count_toj 
port map( data => data, 
w up_dn => up_dn, 

load => load, 
cen => T, 
elk => TCLK, 

15 

reset => RN, 
count => count, 
tercnt => tercnt) ; 
20 up_dn <= up; 

tercnt 1 <= tercnt; 

RN <= not R; 

data <= zero; 

25 

hugol : process (TCLK, T) 
begin 

30 if (T = »l f ) 

then load <= 1 1 ' ; 
else load <= 1 0 1 ; 

6 end if; 
end process; 



hugo? : process (tercnt, T, RN) 

40 

begin 

if ( T = f 0 f or RN = f 0 f ) then Q <= •On- 
load <= '0 ? ; 

45 elsif (tercnt 1 event and tercnt = 'l 1 ) then 

Q <= f l'; 
end if; 
end process; 

end fup; 



55 
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— pragma translate_of f 

configuration tbictr_scnto_cfg of setimer is 

for fup 
for U0: 

DW03Jbictr_scnto use 

configuration DW03 . DW03Jbictr_scnto_cf g_sim; 
end for; 
end for; 
end tbictr_scnto_cfg; 
— pragma translate_on 



Zusammenfassend ergeben sich folgende Verfahrensschritte des Verfahrens zur Verifikation eines SPS-Pro- 
gramms, die in Rg. 7 dargesteltt sind. 

Mindestens eine zu verf izierende Eigenschaft VE des SPS-Programms SProg wird in einer formalen Spezrfikati- 
onssprache formutiert. Das SPS-Programm SProg wird auf einen endtichen Automaten abgebildet 701. Der endliche 
Automat wird unter Verwendung von BDDs beschrieben 702. Die zu verif izierende Eigenschaft wird unter Verwendung 
der symbolischen ModellGberprufung uberpruft 703. 

Es ist jedoch in einer Weiterbildung des Verfahrens ebenso vorgesehen. auch die Eigenschaften VE auf den end- 
lichen Automaten zusammen mit dem SPS-Programm SProg abzubilden. 

Eine regressive Ueberpruefung eines SPS-Programms SProg nach Anderungen ist ein Spezialfall der hier 
beschriebenen Modelluberprufung und kann wie folgt durchgefuhrt werden. 

Das ursprungliche SPS-Programm SProg wird - wie oben beschrieben wurde- durch einen ersten Automaten A 
modelliert Das gednderte SPS-Programm SProg* wird ebenfalls in der dargestellten Wetse durch einen zweiten Auto- 
maten A' modelliert. 

Aus diesen beiden Automaten A, A' wird z. B. analog dem in dem Dokument [7] beschriebenen Verfahren ein Pro- 
duktautomat AProd konstruiert; dabei werden nur diejenigen Ausgdnge berucksichtigt, deren Verhaiten nicht geandert 
wurde. 

Die beiden SPS-Programme verhaiten sich bzgl. der nicht geanderten Ausgdnge Equivalent, wenn der Ausgang 
des Produktautomaten Aprod immer den Wert TRUE lief ert. Diese Eigenschaft des Produktautomaten Aprod wird unter 
Verwendung der symbolischen Modelluberprufung uberpruft. 

Auch diese Oberprufung kann ggf. unter Annahmen uber das gesteuerte System stattfinden. Wetterhin brauchen 
ggf. nicht alle Teile des SPS-Programms SProg detailliert modelliert zu sein. Haufig reicht es aus, Teilkomponenten, 
von denen dquivalentes Verhaiten bekannt ist, als Black-Boxes zu betrachten. 

Unter dem Ausdruck "Anderung eines SPS-Programms" ist in diesem Zusammenhang u.a die Neuformulierung 
(ggf. sogar in einer anderen, besser geeigneten SPS-Sprache, wie z.B. in Zustandsgraphen anstelle in AWL), aber 
auch lokale Anderungen und Ergdnzungen der ursprunglichen Programmquelle zu verstehen. 

Im Rahmen dieses Dokumentes wurden folgende VerOffentlichungen zitiert: 

[1] C. Hoare, An Axiomatic Basis for Computer Programming, CACM, 12, S. 576 - 580, 1969 

[2\ R. Bryant, Symbolic Boolean Manipulation with Ordered Binary-Decision Diagrams, ACM Computing Survey, 
Vol. 24, Nr. 3, S. 293 - 318, Sept 1992 

[3] J. Burch et al, Symbolic Model Checking for Sequential Circuit Verification, IEEE Trans, on Computer-Aided 
Design of Integrated Circuits and Systems, Vol. 13, Nr. 4, S. 401 - 424, April 1994 

[4] T. Filkorn, M. Payer, P. Warkentin, Symbolic Verification of Sequential Circuits Synthesized with CALLAS, 6th 
Internal Workshop on High-Level Synthesis, Laguna Nigel, CA, S. 1 - 10, 1992 

[5] G. DOhmen et al, Translating VHDL into Functional Symbolic Finite-State Models, Kluwer Academic Publishers, 
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Boston, Formal Methods in System Design, ISSN 0925-9856, S. 125 - 148, 1995 

[6| G. DGhmen und R. Herrmann, A Deterministic Finite-State Model vor VHDL, Kluwer Academic Publishers, For- 
mal Semantics for VHDL C. KJoos und P. Breuer (EDS), ISBN 0-7923-9552-2, S. 1 - 43, 1995 

[7] T. Filkorn, A Method for Symbolic Verification of Synchronous Sequential Circuits, CHDL 91 - Computer Hard- 
ware Description Languages and their Application, April 1991, Editors D. Borrione and R. Waxman, S. 229-239, 
Marseille, France, 1991 

Patentanspruche 

1. Verfahren zur Verrfikation eines Programms (SPS), welches in einer Sprache der Speicher-Programmierbaren- 
Steuerung vorliegt, durch einen Rechner (R), 

bet dem mindestens eine zu verif izierende Eigenschaft (VE) des Programms (SPS) in einer formalen Spezrf i- 
kationssprache vorliegt, 

bei dem das Programm (SPS) auf mindestens einen endlichen Automaten abgebildet wird (701), 

bei dem der endliche Automat unter Verwendung von mindestens einem Binary Decision Diagram (BDD) 

beschrieben wird (702), und 

bei dem die zu verifizierende Eigenschaft (VE) des als Binary Decision Diagram beschrieben en Programms 
(SPS) unter Verwendung der Symbolischen Modelluberprufung (Symbolic Model Checking) uberpruft wird 
(703). 

2. Verfahren nach Anspruch 1 , 

bei dem die Eigenschaft (VE) und das Programm (SPS9 auf mindestens einen endlichen Automaten abgebildet 
wird, 

3. Verfahren nach Anspruch 1 oder 2, 

bei dem als die Sprache der Speicher-Programmierbaren-Steuerung eine Zustandsgraphen-Beschreibungsspra- 
che verwendet wird. 

4. Verfahren nach einem der Anspruche 1 bis 3, 

bei dem als die Sprache der Speicher-Programnm'erbaren-Steuerung eine Beschreibungssprache, welche Anwei- 
sungslisten enth&tt, verwendet wird. 

5. Verfahren nach einem der Anspruche 1 bis 4, 

bei dem die Etgenschaften und das Programm vor der Abbildung auf den endlichen Automaten auf erne Syntax in 
VHDL abgebildet wird. 

6. Verfahren nach einem der Anspruche 1 bis 5, 

bei dem mindestens eine Annahme uber Rahmenbetingungen des Programms (SPS) in einer formalen Spe- 
zifikationssprache vorliegt und 

bei dem die Annahme gemeinsam mit der Eigenschaft (VE) bei der formalen Verrfikation (FM) des Programms 
(SPS) berucksichtigt wird. 

7. Verfahren nach einem der Anspruche 1 bis 6, 

bei dem fur den Fall, daB das Programm (SPS) die zu verifizierende Eigenschaft (VE) nicht aufwetst, eine WfcJer- 
legungssequenz (WS) errrrittelt wird, gespeichert wird und einem Benutzer bei Bedarf angezeigt wird, in der dieje- 
nige Testsequenz mit den TestgrOBen beschrieben wird, die zu dem Ergebnis fuhrte, daB das Programm die zu 
verifizierende Eigenschaft nicht aufweist 

8. Verwendung des Verfahrens nach einem der Anspruche 1 bis 7 zur regressiven Uberprufung des SPS-Programms 
(SProg) nach Anderungen des SPS-Programms (SProg) 
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FIG 7 



701 



702 



703 



Abbildung eines SPS-Programms 
auf einen endlichen Automaten 



I 



Beschreibung des endlichen Automaten 
mit Binary Decision Diagrams 



I 



Verifikation einer zu verifizierenden 
Eigenschaft des ais Binary Decision 
Diagram beschriebenen SPS-Programms 
mit Symbolic Model-Checking 
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